Newlook's recognition engine underpins all products in the Newlook Suite. This engine uses a complex pattern-matching algorithm to analyze the incoming 5250 data stream, and convert it into a graphically rich user interface. Every IBM i screen element (also known as "host screen field") is classified into a particular category by the recognition engine, which in turn is converted to a graphical object. Categories are classified according to the following information:
For example... If the recognition engine detects multiple field choice values associated with a particular data entry field on a 5250 screen, provided Option Buttons Recognition is enabled in Rules, an Option button control will be generated on the resulting form. This behavior can be overridden by a form override which explicitly instructs the recognition engine to either hide the control, or use a different category to generate the control.
While pattern matching components are based on IBM's CUA design guidelines, you can control which pattern detection components are active. Rules are also context-sensitive, support special cases and can be customized to cater for common patterns found in your applications and non-CUA compliant applications.
The recognition engine is optimized for the IBM i 5250 data stream, especially when it comes to the detection of items like command entry fields, which generate combo boxes with support for previous command recall. Similarly, the detection of a particular custom defined subfile (grid) marker can generate the appropriate grid paging options.
Examples of recognition engine customizations include:
The Newlook recognition engine operates within a dynamic "real-time" environment where host screen conversions occur "on-the-fly". The dynamic graphical interface is generated instantly based on the execution-time state of the host application. Because the recognition engine does not need to store captured "green screen" images, most typical changes made to the underlying application are correctly reflected in the "just-in-time" generated interface.
This dynamic architecture avoids the process of analyzing host applications in batch mode to produce an intermediate GUI specification, which is then subsequently compiled, resulting in an additional set of interface specifications that need to be maintained each time the underlying application is changed.
All components within Newlook have a dynamic architecture. Any defined item can be used immediately.
For example... Newlook's Design tool can be used to create a form. Upon opening the runtime client, it runs immediately. While it's executing, you can re-open Design, add, remove or modify objects on your new form, save the form and your revised design executes immediately in the runtime client.
This dynamic architecture provides a faster, simpler way to get things done, dramatically improving productivity and IT’s ability to rapidly respond to business user requirements.
![]() |
![]() |
The Dynamic recognition repository (or shared .sid file) stores all of your custom Newlook data. This data is stored in a "ready-to-execute" state and can be located on a server or client machine (depending on how the product is installed).
When you first connect to your host application, the recognition engine will automatically generate a graphical UI based on default settings contained in your Shared repository. The Shared repository file can be thought of as a rule book for the recognition engine. The information contained in it dictates the way the incoming 5250 datastream is interpreted. As you customize your generated interface, you will need to make use of the core Newlook Developer tools; Settings, Rules, Design, Identify and the Logic editors, to fine tune the default recognition and extend to your application. The types of changes you can make to your application include refining the look and feel of generated screens, designing web-optimized screens for your application, integrating with other desktop software, adding field validation, creating custom forms and functions and adding transactions to eliminate redundant steps and improve workflow.
The main tools used to add custom data to your Design Repository include:
Typically one Shared Repository (or shared .sid file) is distributed to all end users, ensuring that all business users experience a consistent GUI representation of the host application. It is possible to design overrides to suit specific channels of deployment, therefore a single sid file can contain different GUIs to cater for different end user environments. It is worth noting that only Newlook Developer licensed users can edit the Shared Repository.
Developing a Newlook project | The Newlook suite
© 2004-2021 looksoftware. All rights reserved.